這一兩年，「用 AI 開發」已經不是一個要不要的問題了。

我自己接的案子裡，從去年開始幾乎每一個都有 AI 參與——分析舊系統、產需求文件、寫程式、補測試、修 bug。客戶也不再問「你們會不會用 AI」，改問「你們用 AI 之後，是不是可以便宜一點、快一點」。

而在這個過程裡，我常常遇到兩種極端的看法——過度樂觀（快了十倍，剩下的只是縮編和壓工期）和過度抗拒（AI 寫的都是垃圾，正式專案不能用）。

兩種都有偏頗。 而我會這樣講，是因為這兩種我自己都經歷過——先是第一種，然後被第二種打了一巴掌。

這件事是怎麼開始的：一個順利的案子

2025 年，我們用 Vibe Coding 做完了某個專案——規模不大、範圍清楚。

沒有規格文件、沒有先設計，就是一直講、一直改、一直跑。而它順利完成了。 功能做出來了，也交付了。

那次之後，我對 AI Coding 的興趣才真正被打開——原來可以這樣做。 而且不只是快：一個人能做到的事情，範圍整個被撐開了。 以前要等別人、要排時間、要學一整套才能碰的東西，現在自己就能推到底。

然後，接下來兩個案子失敗了。

不是「有點不順」，是走到客戶要求重做、走到驗收不過。而失敗的方式跟第一次的成功一樣讓人意外——它們都不是敗在寫不出程式。

這兩個案子的形狀，我要先說清楚，因為它會決定你怎麼讀後面四十幾天。

一個是接手救火：前面已經有廠商執行失敗、時程嚴重不足，客戶想知道能不能用 AI 快速做出來。我們提了要求——請你們寫出測試案例當基準——而客戶答不出來，因為他們自己也不知道那套系統怎麼運作。

另一個是我們照著規範做了、還做成機器檢查，我當時有信心說產出絕對符合規範。然後客戶說不符合——因為他真正在用的那套，跟他給我們的文件不一樣。

所以這兩件事我不會用「我們失敗了」來收。它們比那個更有用：

一個告訴我「在建造之前要先明白你要建造什麼」。
一個告訴我「你很在意的東西，務必要講清楚」。

而後面那些做到了的案子，用的就是這兩句話。

所以我們停了下來，問一個問題：

AI 讓我們變快了，也把個人能力的上限解放掉了。
那之後，到底發生了什麼事？

回到軟體的本質，再回來談 AI

想了一陣子，我目前的答案是這樣：問題不在工具，在我們把「開發」這件事想得太窄了。

寫程式從來就不只是把功能生出來。它同時是在建立一套關於這個系統的理論——為什麼這裡要這樣切、這個欄位為什麼必填、這個例外當初為什麼決定吞掉。這套理論長在人的腦袋裡，程式碼只是它的一個投影。

而理論要能被建立、被傳下去、被檢驗，靠的是工程手段：規格、審查、測試、版本、紀錄。這些東西存在的理由從來不是為了好看，是為了讓「我們到底懂不懂這個系統」有辦法被檢查。

那 AI 改變了什麼？

它把產出的速度變快了。其他沒動。

所以瓶頸只是換了位置：

以前   想得快、做得慢       →   瓶頸在產出
現在   做得快               →   瓶頸移到「怎麼知道做出來的是對的」

而那個案子之所以順利，現在回頭看，不是因為 Vibe Coding 好用——是因為那個案子的理論夠小、夠新、而且完整地存在我一個人的腦袋裡。後面兩個失敗的案子都不是這樣：一個是十幾年的舊系統（理論散在別人身上，而且大部分已經流失），一個是客戶有一整套自己的規範（理論存在對方那邊）。

所以我認為順序不能倒過來：

先把軟體工程的本質擺回中間，再談 AI 怎麼輔助。
不是先有 AI，然後叫工程去配合它。

從這裡，才會走到整個系列的那句話：

問題不在「AI 產出的品質」，在「我們驗收的方式」。

為什麼我要寫這個系列

有三個理由。

第一，這一年的教訓散落在八個專案裡，沒有整理就會消失。

每個案子結束的時候，大家心裡都有數——「這次哪裡沒做好」「下次要注意什麼」。但「心裡有數」不是資產。它不能交接、不能被檢驗，三個月後就變形了。

所以我想趁著還記得，把它整理成可以拿出來討論的東西。

第二，我想講的東西，市面上比較少人講。

現在談 AI 開發的內容，大部分集中在「怎麼下 prompt」「哪個工具比較好」「怎麼讓 AI 寫出漂亮的 code」——全部是產出面。

我這一年真正被咬的地方，幾乎都在驗收面：東西產出來了，看起來很正常，但沒有人能確定它對不對。

第三，也是最主要的：我手上同時有失敗和成功，而我想弄清楚它們的差別在哪。

先把牌攤開。這一年帶著 AI 做了八個案子——有內部系統、有客戶專案、有投標案：兩個失敗（一個已結案、客戶要求重做；一個仍在重工）、三個做到了（但都還沒走到終點）、三個進行中。

而失敗和做到了的那些，出自同一群人、同一段時間。

所以這不是一份檢討報告。失敗案例的價值我知道——它告訴你哪裡會出錯，而你很可能踩到同一個坑；成功案例則太看運氣、看團隊、看客戶，你不會照抄。

但這兩句話都太便宜了。 真正有意思的是那個對照本身：同一批人，前面垮掉，後面沒垮。中間發生了什麼？

我花了四十幾天在追這個問題。我會給你我目前的答案，但也會在最後把帳算清楚——包括哪幾條我其實沒有證據。

(先說：這些是我目前的認知，不一定完全正確。有些結論我到現在都還沒有把握，會在文章裡明說。歡迎指教。)

一點說明

這個系列會用到那八個案子的數據。全部經過去識別處理——不會出現客戶名稱、產業別、系統代號、資料表名、真實畫面。保留的是機制、數字量級和時間軸，因為那才是有參考價值的部分。

有些數字我做了模糊化，有些保持原樣。凡是我寫「大約」的就是不精確，沒寫的就是原始數字。

工具與模型的揭露，我要放在這裡而不是藏在附錄。

這個系列裡所有跟 AI 協作的部分，用的都是 Claude Code。而模型——是各次執行當下的預設模型。

這句話有一個我必須點出來的問題：那 43 次執行橫跨大約兩個半月，期間預設模型改過版，而我沒有逐次記錄。所以嚴格說起來，那批數字是「在那段期間、用當時的預設模型跑出來的」，不是「用某一個特定模型跑出來的」。

（工具與模型的完整揭露、以及這個系列所有已發布的更正，我另外整理成一份勘誤頁，會持續更新。連結放在每一篇的文末。）

這代表那些數字的可複現性是有折扣的。 我沒辦法給你一個「換上同一個模型就能重跑」的條件——這是我在整理的時候才發現的缺口，補不回去了。寫出來，總比讓你以為它可複現好。

還有一件要先說在前面的，因為它涵蓋整個系列。 後面會有很多句子長成「AI 會怎樣」「AI 不會停下來問」「它沒有那個焦慮」這種形狀。那些全部是我在一段時間內、用特定幾個模型、在特定幾個專案上觀察到的行為模式，不是模型規格，也沒有做過對照實驗。 模型會改版，這些觀察不保證明年還成立。我在文中不會每次重複這句話，但它對每一句都適用。

另外，日期我一律換成了相對時序（第幾個月、第幾輪），絕對行數也大多收成量級。 因為案子既然去識別化了，「1 月 22 日」「2,206 行」對你就沒有意義——有意義的是形狀和比值：規範全部出現在問題之後、深度分布是雙峰的、一批問題單背後其實只有一半數量的 bug。那些我一個都沒動。

另外要說清楚：這些案子全部出自同一個團隊、同一段時間。

所以後面講「為什麼一開始不行、後來行」的時候，那是連續的軌跡，不是「別人做得比較好」——這也是我覺得這個系列還算有點價值的地方。

明天開始拆第一個案子——那個做了四個月、最後客戶來協商要找人重做的案子。

參考文獻

1. Naur, P.（1985）。Programming as Theory Building。Microprocessing and Microprogramming, 15(5), 253–261。
   後收錄於 Naur, P.（1992）。Computing: A Human Activity。ACM Press／Addison-Wesley，頁 227–240。
   — 「寫程式是在建立一套理論、而理論存在人身上」出自這篇。

本系列所有案例均經去識別處理，不指涉任何特定客戶、系統或產業。
工具：Claude Code；模型：各次執行當下的預設模型。